From: Jonathan A. <eag...@gm...> - 2014-01-10 07:03:06
|
I was speaking with toby last night while all these discussions were going on, and I am going to get things going with moving the current 0.4 stable branch to git hub. This will function as our new master branch. I will also create another branch specifically for UI development. Once we have a UI we like I will merge the changes into the master branch and rebase the 0.4 according to those changes. I think from now on we should adopt the mentality that all patches should be based against the master branch and then cherry picked to the branches upon approval by someone such as toby and Paul (pgib on irc) that they are not going to cause serious problems with the stable branch and any future stable releases. Any and all new features should go in the master branch. I am also going to be migrating bugs to the bug tracker that comes with github Toby is there anything else you would like to add here? -- Jonathan Aquilina |
From: Tobias D. <tob...@gm...> - 2014-01-10 08:34:26
|
Hi, 2014/1/10 Jonathan Aquilina <eag...@gm...> > I think from now on we should adopt the mentality that all patches should > be based against the master branch > To be clear: not the old master branch but either a new one we're going to create or even better: stable-0.4! Otherwise the patches won't apply. IMHO we should go away from the concept of stable and development branches. Instead there should be one branch where stabilized feature branches get merged in. Every N weeks there should be a release. Of course we can still provide an experimental branch where all feature branches regularly get merged in (for users wanting to use bleeding edge unstable LMMS) but development should not happen against this experimental/master branch. > and then cherry picked to the branches upon approval by someone such as > toby and Paul (pgib on irc) > Based on the experiences in the past, we should try to avoid cherry-picking and use feature branches instead to make sure the code base is not diverging and merging is always possible without conflicts. Toby |
From: Jonathan A. <eag...@gm...> - 2014-01-10 09:25:05
|
Toby its your call. I really need to have a chat with you. Is it possible to get like admin access so i can create tags for the bugs I am going to be migrating over to the tracker on git hub please. On Fri, Jan 10, 2014 at 9:34 AM, Tobias Doerffel <tob...@gm...>wrote: > Hi, > > 2014/1/10 Jonathan Aquilina <eag...@gm...> > >> I think from now on we should adopt the mentality that all patches should >> be based against the master branch >> > > To be clear: not the old master branch but either a new one we're going to > create or even better: stable-0.4! Otherwise the patches won't apply. > > IMHO we should go away from the concept of stable and development > branches. Instead there should be one branch where stabilized feature > branches get merged in. Every N weeks there should be a release. Of course > we can still provide an experimental branch where all feature branches > regularly get merged in (for users wanting to use bleeding edge unstable > LMMS) but development should not happen against this experimental/master > branch. > > >> and then cherry picked to the branches upon approval by someone such as >> toby and Paul (pgib on irc) >> > > Based on the experiences in the past, we should try to avoid > cherry-picking and use feature branches instead to make sure the code base > is not diverging and merging is always possible without conflicts. > > Toby > -- Jonathan Aquilina |
From: David G. <dg...@gm...> - 2014-01-10 10:29:39
|
On 10 January 2014 08:34, Tobias Doerffel <tob...@gm...> wrote: > To be clear: not the old master branch but either a new one we're going to > create or even better: stable-0.4! Otherwise the patches won't apply. > IMHO we should go away from the concept of stable and development branches. > Instead there should be one branch where stabilized feature branches get > merged in. Every N weeks there should be a release. Of course we can still > provide an experimental branch where all feature branches regularly get > merged in (for users wanting to use bleeding edge unstable LMMS) but > development should not happen against this experimental/master branch. Excellent! Will the distro package maintainers be able to keep up with this? (Will the distros let them?) - d. |
From: Vesa <di...@nb...> - 2014-01-10 10:31:30
|
On 01/10/2014 12:29 PM, David Gerard wrote: > On 10 January 2014 08:34, Tobias Doerffel <tob...@gm...> wrote: > >> To be clear: not the old master branch but either a new one we're going to >> create or even better: stable-0.4! Otherwise the patches won't apply. >> IMHO we should go away from the concept of stable and development branches. >> Instead there should be one branch where stabilized feature branches get >> merged in. Every N weeks there should be a release. Of course we can still >> provide an experimental branch where all feature branches regularly get >> merged in (for users wanting to use bleeding edge unstable LMMS) but >> development should not happen against this experimental/master branch. > > Excellent! Will the distro package maintainers be able to keep up with > this? (Will the distros let them?) > Probably depends on the distro... |
From: Tobias D. <tob...@gm...> - 2014-01-10 10:31:35
|
2014/1/10 David Gerard <dg...@gm...> > Excellent! Will the distro package maintainers be able to keep up with > this? (Will the distros let them?) > What do you mean? It's up to the packagers to maintain packages based on official releases. |
From: David G. <dg...@gm...> - 2014-01-10 10:33:54
|
On 10 January 2014 10:31, Tobias Doerffel <tob...@gm...> wrote: > 2014/1/10 David Gerard <dg...@gm...> >> Excellent! Will the distro package maintainers be able to keep up with >> this? (Will the distros let them?) > What do you mean? It's up to the packagers to maintain packages based on > official releases. I know, I'm presuming the package maintainers (e.g. Israel) are here and can answer :-) - d. |
From: Israel <isr...@gm...> - 2014-01-10 13:44:16
|
Yes, for some distros (Arch) that always allow bleeding edge releases. No, for some distros (Ubuntu) that always prefer stable applications. The Debian maintainer for LMMS was MIA last I knew, so Debian will be stuck at 0.4.10 until someone can update it. Ubuntu specific: When a new release of LMMS comes out, it will automatically be checked out by launchpad when I point the package to look at the GitHub stable branch. So when the next release comes along, if it is before feature freeze, I can get the new version into Ubuntu. If a new version comes along after a release, you will have to use/make a ppa. ESPECIALLY for LTS. Those are *very* hard to get new packages in, although possible, but usually only security fixes (with exception to certain programs, like Firefox) > Excellent! Will the distro package maintainers be able to keep up with > this? (Will the distros let them?) - d. -- Regards |
From: Jonathan A. <eag...@gm...> - 2014-01-10 13:45:41
|
I am learning to package it so I could potentially take over maintaining it once I get used to packaging On Fri, Jan 10, 2014 at 2:44 PM, Israel <isr...@gm...> wrote: > Yes, for some distros (Arch) that always allow bleeding edge releases. > No, for some distros (Ubuntu) that always prefer stable applications. > The Debian maintainer for LMMS was MIA last I knew, so Debian will be > stuck at 0.4.10 until someone can update it. > Ubuntu specific: > When a new release of LMMS comes out, it will automatically be checked > out by launchpad when I point the package to look at the GitHub stable > branch. So when the next release comes along, if it is before feature > freeze, I can get the new version into Ubuntu. If a new version comes > along after a release, you will have to use/make a ppa. ESPECIALLY for > LTS. Those are *very* hard to get new packages in, although possible, > but usually only security fixes (with exception to certain programs, > like Firefox) > > > Excellent! Will the distro package maintainers be able to keep up > with > this? (Will the distros let them?) - d. > > -- > Regards > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > -- Jonathan Aquilina |
From: Israel <isr...@gm...> - 2014-01-10 13:56:48
|
@Jonathon Aquilina Are you looking to take over Debian packaging? That would be great! On 01/10/2014 07:45 AM, Jonathan Aquilina wrote: > I am learning to package it so I could potentially take over > maintaining it once I get used to packaging > > > On Fri, Jan 10, 2014 at 2:44 PM, Israel <isr...@gm... > <mailto:isr...@gm...>> wrote: > > Yes, for some distros (Arch) that always allow bleeding edge releases. > No, for some distros (Ubuntu) that always prefer stable applications. > The Debian maintainer for LMMS was MIA last I knew, so Debian will be > stuck at 0.4.10 until someone can update it. > Ubuntu specific: > When a new release of LMMS comes out, it will automatically be checked > out by launchpad when I point the package to look at the GitHub stable > branch. So when the next release comes along, if it is before feature > freeze, I can get the new version into Ubuntu. If a new version comes > along after a release, you will have to use/make a ppa. > ESPECIALLY for > LTS. Those are *very* hard to get new packages in, although possible, > but usually only security fixes (with exception to certain programs, > like Firefox) > > > Excellent! Will the distro package maintainers be able to keep up > with > this? (Will the distros let them?) - d. > > -- > Regards > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > <mailto:LMM...@li...> > https://lists.sourceforge.net/lists/listinfo/lmms-devel > > > > > -- > Jonathan Aquilina -- Regards |
From: Jonathan A. <eag...@gm...> - 2014-01-10 13:58:23
|
I can but I wont even bother with down stream ubuntu as they pull their stuff from debian, I would just need to monitor to make sure things get updated for new releases. It will be some time i think though before I am ready. On Fri, Jan 10, 2014 at 2:56 PM, Israel <isr...@gm...> wrote: > @Jonathon Aquilina > Are you looking to take over Debian packaging? That would be great! > > > On 01/10/2014 07:45 AM, Jonathan Aquilina wrote: > > I am learning to package it so I could potentially take over maintaining > it once I get used to packaging > > > On Fri, Jan 10, 2014 at 2:44 PM, Israel <isr...@gm...> wrote: > >> Yes, for some distros (Arch) that always allow bleeding edge releases. >> No, for some distros (Ubuntu) that always prefer stable applications. >> The Debian maintainer for LMMS was MIA last I knew, so Debian will be >> stuck at 0.4.10 until someone can update it. >> Ubuntu specific: >> When a new release of LMMS comes out, it will automatically be checked >> out by launchpad when I point the package to look at the GitHub stable >> branch. So when the next release comes along, if it is before feature >> freeze, I can get the new version into Ubuntu. If a new version comes >> along after a release, you will have to use/make a ppa. ESPECIALLY for >> LTS. Those are *very* hard to get new packages in, although possible, >> but usually only security fixes (with exception to certain programs, >> like Firefox) >> >> > Excellent! Will the distro package maintainers be able to keep up >> with > this? (Will the distros let them?) - d. >> >> -- >> Regards >> >> >> >> ------------------------------------------------------------------------------ >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> _______________________________________________ >> LMMS-devel mailing list >> LMM...@li... >> https://lists.sourceforge.net/lists/listinfo/lmms-devel >> > > > > -- > Jonathan Aquilina > > > > -- > Regards > > -- Jonathan Aquilina |