separate branch for releases
Locked
separate branch for releases
 
|
Hello!
When was the last release, everybody was told that 2 weeks before the release, no features must be commited in branch master, only bugfixes. i thinks is not right to stop the development process and i have a small suggestion:
A month before release of certain version of digikam, to create a separate branch, where only bugfixes and be applied.I don't know, maybe to apply bugfixes on both master and new release branch and delete the branch or simply to add bugfixes and merge the branch after release.
Also, branch can give us more time for testing, so we could prevent situations like these:
and development process won't stop especially when you need to apply fixes that depends on code that wasn't commited yet. What do you think? p.s. Idea was "stolen" from Karl Fogel's book, Producing Open Source Software :)
Best,
Veaceslav _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Yes, might be a better idea than I had. Just test before upload. But
not very usefull if it is uploaded while the tests are in progress.
Maybe this works better.
Rinus Op 19-09-11 20:49, Veaceslav Munteanu schreef: Hello! _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: separate branch for releases
|
|
In reply to this post by Veaceslav Munteanu
> When was the last release, everybody was told that 2 weeks before the > release, no features must be commited in branch master, only bugfixes. > > i thinks is not right to stop the development process and i have a small > suggestion: > > A month before release of certain version of digikam, to create a separate > branch, where only bugfixes and be applied.I don't know, maybe to apply > bugfixes on both master and new release branch and delete the branch or > simply to add bugfixes and merge the branch after release. > > Also, branch can give us more time for testing, so we could prevent > situations like these: > https://bugs.kde.org/show_bug.cgi?id=281767 > > and development process won't stop especially when you need to apply fixes > that depends on code that wasn't commited yet Suggestions like these are fully justified in larger projects. If you look at the commit log of digikam, you'll see Gilles, me, and Francesco doing the majority of commits. Who is going to backport bug fixes? Who is going to maintain the branch? Who is going to test it? There is another point: A commit freeze forces developers to do bug fixing. Feature development is fun, bug fixing is tedious. So we need to force ourselves to do it. Third, with git, it is possible to have either local commits or even local or remote feature branches if a larger patch is to be developed.7 Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Op 19-09-11 22:13, Marcel Wiesweg schreef:
>> When was the last release, everybody was told that 2 weeks before the >> release, no features must be commited in branch master, only bugfixes. >> >> i thinks is not right to stop the development process and i have a small >> suggestion: >> >> A month before release of certain version of digikam, to create a separate >> branch, where only bugfixes and be applied.I don't know, maybe to apply >> bugfixes on both master and new release branch and delete the branch or >> simply to add bugfixes and merge the branch after release. >> >> Also, branch can give us more time for testing, so we could prevent >> situations like these: >> https://bugs.kde.org/show_bug.cgi?id=281767 >> >> and development process won't stop especially when you need to apply fixes >> that depends on code that wasn't commited yet > Suggestions like these are fully justified in larger projects. If you look at > the commit log of digikam, you'll see Gilles, me, and Francesco doing the > majority of commits. Who is going to backport bug fixes? Who is going to > maintain the branch? Who is going to test it? > There is another point: A commit freeze forces developers to do bug fixing. > Feature development is fun, bug fixing is tedious. So we need to force > ourselves to do it. learn it new tricks that you forget to cure it. Who are you going to learn new tricks if your baby dies. If I only could program at your level I would care my baby uh your baby, and cure carefully any little itch. I can see clearly that this is some real problem here. The project need more programmers. Is there not a way to attract them. Go commercial? Work together with a local school? A project like digikam should be able to make enough money to pay it´s programmers. It is a diamond. 6000000000 photographing people and no competition at this level. Imagine, dream... Send a letter to Bill. Best regards, Rinus > Third, with git, it is possible to have either local commits or even local or > remote feature branches if a larger patch is to be developed.7 > > Marcel > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: separate branch for releases
|
|
2011/9/20 sleepless <[hidden email]>:
> Op 19-09-11 22:13, Marcel Wiesweg schreef: >>> >>> When was the last release, everybody was told that 2 weeks before the >>> release, no features must be commited in branch master, only bugfixes. >>> >>> i thinks is not right to stop the development process and i have a small >>> suggestion: >>> >>> A month before release of certain version of digikam, to create a >>> separate >>> branch, where only bugfixes and be applied.I don't know, maybe to apply >>> bugfixes on both master and new release branch and delete the branch or >>> simply to add bugfixes and merge the branch after release. >>> >>> Also, branch can give us more time for testing, so we could prevent >>> situations like these: >>> https://bugs.kde.org/show_bug.cgi?id=281767 >>> >>> and development process won't stop especially when you need to apply >>> fixes >>> that depends on code that wasn't commited yet >> >> Suggestions like these are fully justified in larger projects. If you look >> at >> the commit log of digikam, you'll see Gilles, me, and Francesco doing the >> majority of commits. Who is going to backport bug fixes? Who is going to >> maintain the branch? Who is going to test it? >> There is another point: A commit freeze forces developers to do bug >> fixing. >> Feature development is fun, bug fixing is tedious. So we need to force >> ourselves to do it. > > See it this way. You are carrying a sick baby around, being so busy to learn > it new tricks that you forget to cure it. Who are you going to learn new > tricks if your baby dies. If I only could program at your level I would care > my baby uh your baby, and cure carefully any little itch. > > I can see clearly that this is some real problem here. The project need more > programmers. Is there not a way to attract them. Go commercial? Work > together with a local school? A project like digikam should be able to make > enough money to pay it´s programmers. It is a diamond. 6000000000 > photographing people and no competition at this level. Imagine, dream... yes, a dream for me (:=)))... Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: separate branch for releases
|
|
In reply to this post by Marcel Wiesweg
On Mon, Sep 19, 2011 at 8:13 PM, Marcel Wiesweg <[hidden email]> wrote: Suggestions like these are fully justified in larger projects. If you look at I've got your point and i know who is workings the most :) someone told me about digikam and i hope that i will tell it to another students, but i can't go faster.
Also i'm sitting on bleeding-edge kde and it's crashing regularly so i can tell it's too far from gnome, but it has tons of features. From this point of view, in future i want to do more bugfixing(so it's not tedious for me), but i lack experience.
Commiting can be done in both branches to avoid backporting them. Extra seconds for someone(to write an extra git command) can save someone from lots of work. Also having few things settled ok from very beginning can make the project grow faster.
Veaceslav _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Wellcome, and bring a bunch of students with you. That´s my point of view. Any objections? Rinus
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Gilles Caulier-4
Op 20-09-11 09:05, Gilles Caulier schreef:
> 2011/9/20 sleepless<[hidden email]>: >> Op 19-09-11 22:13, Marcel Wiesweg schreef: >>>> When was the last release, everybody was told that 2 weeks before the >>>> release, no features must be commited in branch master, only bugfixes. >>>> >>>> i thinks is not right to stop the development process and i have a small >>>> suggestion: >>>> >>>> A month before release of certain version of digikam, to create a >>>> separate >>>> branch, where only bugfixes and be applied.I don't know, maybe to apply >>>> bugfixes on both master and new release branch and delete the branch or >>>> simply to add bugfixes and merge the branch after release. >>>> >>>> Also, branch can give us more time for testing, so we could prevent >>>> situations like these: >>>> https://bugs.kde.org/show_bug.cgi?id=281767 >>>> >>>> and development process won't stop especially when you need to apply >>>> fixes >>>> that depends on code that wasn't commited yet >>> Suggestions like these are fully justified in larger projects. If you look >>> at >>> the commit log of digikam, you'll see Gilles, me, and Francesco doing the >>> majority of commits. Who is going to backport bug fixes? Who is going to >>> maintain the branch? Who is going to test it? >>> There is another point: A commit freeze forces developers to do bug >>> fixing. >>> Feature development is fun, bug fixing is tedious. So we need to force >>> ourselves to do it. >> See it this way. You are carrying a sick baby around, being so busy to learn >> it new tricks that you forget to cure it. Who are you going to learn new >> tricks if your baby dies. If I only could program at your level I would care >> my baby uh your baby, and cure carefully any little itch. >> >> I can see clearly that this is some real problem here. The project need more >> programmers. Is there not a way to attract them. Go commercial? Work >> together with a local school? A project like digikam should be able to make >> enough money to pay it´s programmers. It is a diamond. 6000000000 >> photographing people and no competition at this level. Imagine, dream... > yes, a dream for me (:=)))... > > Gilles > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > right here... Rinus _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |